


The Universal Serial Bus 


(USB) 


By B. Kainka 





Part 2: Transfers and Drivers 


In the first part of this article we looked at the electrical characteristics 
of the USB standard. In this part we investigate the software and protocols 
used with this interface. Also included is a practical programming example. 
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When any new device is first 
plugged in to the USB connector, it 
will signal its presence to the hub by 
pulling up one of the two data wires 
of the USB cable. Next comes the fol- 
lowing sequence of events: 


- The hub indicates to the host that a 
new device has been connected to 
the bus. 

-The host will ask the hub which 
port the device will use. 

- Now the host knows which port 
the device will use, it enables the 
port and issues a bus reset com- 
mand to the hub. 

- The hub generates a reset signal on 
the bus by pulling both data lines 
D+ and D- low for 10 ms. After 
reset, the device is ready and will 
respond using the default address 0. 

- Until the device is assigned its own 
bus address it will use the default 
address. The host will read the first 
bytes of the device descriptor to 
determine the length of the data 
packet in order to assign a length 
to the default pipe. 

- The host will allocate a bus address 
to the device. 

- The host will now read all the con- 
figuration information from the 
device using its newly allocated 
bus address. 

- The host assigns one of the possible 
configurations to the device. The 
current consumption of the device 
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Figure |. Screen shot of the USB 
Thermostat. 


must not be more than that defined 
in its configuration descriptor. The 
device is now ready for use. 


The microcontroller in the USB 
device responds to each message 
from the host. A hardware interrupt 
will indicate that data has been 
received and is available in FIFO 0. 
The data is analysed to determine 
what type of message it is. Key 
bytes in the data packet request the 
device descriptor. The microcon- 
troller will respond by reading the 
requested information from its ROM 
and writing it to its output FIFO. 
From there it will be sent back to the 
master. The first descriptor sent will 
be the device descriptor which has a 
length of 18 bytes. The host will ini- 
tially take the first 8 bytes. After the 
host has assigned the device 
address, it will read the rest of the 
descriptor. The 18 data bytes will be 
spread over three frames to enable it 
to fit into the 8 byte FIFO. 

Table 1 shows the Device 
Descriptor of the USB Thermometer 
from Cypress, which was featured in 
part 1 of this series. Each device 
requires a Vendor-ID and a device ID. 
Using these numbers, the device is 
recognised and the corresponding 
driver software is loaded from the 
host to the device. The Vendor-ID is 
assigned under license to a device 
manufacturer by the USB Organisa- 
tion. Those who intend to make a 
serious business of developing USB 
devices must also arrange for their 
own vendor ID. 

For the hobbyist it is in theory 
possible to unofficially make up your 
own VID. This will entail writing 
your own driver and a .INF file to 
configure the device. If we carried on 
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Figure 2. Mini hardware driver for the 
Heater Controller. 


down this road you can probably see 
that eventually the whole ‘Plug and 
Play’ concept would be undermined 
by device manufacturers assigning 
themselves identical VID’s leading 
to all sorts of confusion. 

For our purposes, the best (and 
perfectly legal) solution is to use the 
vendor ID of the semiconductor man- 
ufacturer corresponding to the USB 
chip in the device. A device incorpo- 
rating the USB Soundchip UDA1321 
would use the VID of its manufac- 
turer i.e. Philips. For the EZ USB Chip 
from Anchor you will use the Anchor 
driver and your own software in the 
controller. 


Types of USB Transfer 


There are currently four completely 
different methods of communicating 
between a USB device and a PC: 


- Control-Transfer 

Used for control signals to the 
device, they have a high priority and 
incorporate automatic error protec- 
tion. Data rate is high and up to 
64 Bytes per request can be sent. 

- Interrupt-Transfer 

Devices such as keyboards and mice 
would generally use this method. 
These devices send small amounts 
of data periodically to the PC. The 
name of this transfer would suggest 
that a hardware interrupt is respon- 
sible for the data flow but this is not 
the case, nor is it possible in a single 
master system. Actually, the system 
looks for new data every 10 ms or so. 
The amount of data sent using this 
transfer would typically be up to 
eight bytes at a time. 

- Bulk-Transfer 

Used to transfer large amounts of 





information that requires error protection but 
is not time critical. Typical applications for 
this method of data transfer would be pass- 
ing data to a printer or receiving data from a 
scanner. The actual data rate is adapted to 
the capacity of the USB system. This method 
has a low priority. 

- Isochronous-Transfer 

Devices transferring large amounts of infor- 
mation at a defined data rate, e.g. digitised 
audio to a soundcard, would use this transfer 
method. A defined data rate is guaranteed 
but no error protection is included. With these 
devices, occasional errors are less important 
than gaps in the data. 


Low-speed devices support control and Inter- 
rupt Transfer modes while full speed devices 
support all four modes. For use in the area of 
control, measurement and regulation the con- 
trol transfer method is particularly useful, it 
offers high data rate together with data error 
protection. The communication protocol is 
comparatively easy to implement for this 
application so for our purposes here we will 
use the control transfer method for the Elek- 
tor Electronics USB Interface. 


Control Transfers in Delphi 


Software drivers are used to control USB 
devices. Conventional methods of controlling 
PC peripherals via their hardware port 
addresses using DOS are no longer possible 
with the USB interface. In order to control a 
device it is necessary to study the documen- 
tation of the driver function. 

Drivers are in principle treated as data 
files. They are opened, you can read or write 
data to them and then they are closed. Pro- 
gramming is very akin to accessing data or 
passing data to and from the RS232 interface. 

For example, writing to a USB printer 
would be performed with WriteFile while 
reading data from a USB scanner would be 
performed with ReadFile. In this example of 
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USB Controllers 


When starting in USB development, it is a good idea to choose a 
USB family, i.e., a microcontroller and/or programming tools 
(Assembler or C compiler), which you are already familiar with 
and which is readily available. Equally important is the amount and 
quality of the supplied documentation. Some companies produce 
Starter Kits that come complete with volumes of software docu- 
mentation 


Philips Semiconductors 

http://www.semiconductor.philips.com 

Produce two interesting full speed-USB-Transceivers. These are similar to 
a UART and can be easily used in existing microcontroller systems or can 
be interfaced to most microcontrollers. 


The PDIUSBDI I with only l6 pins uses an l2?C-Bus-Interface for easy 
connection to a microcontroller. The chip contains 4 end points and two 
8-bit FIFOS for In- and Out-transfers. 


- Full speed-USB 

- I2C Bus Interface up to | Mbit/s 

- 12 MHz crystal, multiplied to 48 MHz internally using a PLL. 
- | Control, 6 generic endpoints (8 Bit Max Packet Size) 

- Package outline: DIP-16 and SO-16 


The PDIUSBD I2 is a full-speed USB-Transceiver with a parallel interface 
compatible with an 805 | Controller. It has three endpoints, which can hold 
from | to 128 bytes. The package has 28 pins but is unfortunately only avail- 
able for SMD mounting. 


- Full-speed USB 

- Parallel Data bus with data rate up to 2 Mbytes/s 
- DMA support 

- Up to IMByte/s in Bulk Mode 

- Up to I Mbit/s in lsochronous Mode 

- | Control, 4 Generic (Dependent on Mode) 

- 320 Bytes (in total) deep FIFO 

- On board 3.3 V voltage regulator 

- Package outline: S028 and TSSOP28 


AnchorChips 

www.anchorchips.com 

The AN2131 is a versatile USB-Controller with a 805 | compatible core. 
The in-built USB Machine is capable of self-enumeration. With this con- 
troller you can build a USB device without writing a single line of code. 
The chip announces itself as an Anchor Default Interface and has all the 
functions and further program code for loading and starting. This simplifies 
the development in the controller. Program download via USB means an 
end to the annoying burn/wipe EPROM cycle normally associated with 
program development. 


- Full speed USB 

- 12 MHz crystal, multiplied to 48 MHz internally using a PLL 
- 8051 Core. 

- Programme Download using USB. 

- I2C interface 

- 8 K internal RAM, expandable to 64 K externally. 

- Package outline: PQFP-44, PQFP-80 


Infineon 

http://www.infineon.de 

Produces the C541U, an 8051 compatible full speed Controller. The pri- 
mary application for this controller is intended to be telecommunications 
e.g. ISDN modems. The controller has external RAM and program mem- 
ory that simplifies development. 


- Full speed USB, selectable low speed 
- 12 MHz crystal 
- 8051 core (C500) 


- 5 V supply with internal 3.3V voltage regulator. 
- SSC (SPI) interface 

-8KOTP 

- external up to 64 K RAM and ROM 

- Package outline: PLCC 44, PSDIP 52 


Cypress 

www.cypress.com 

Cypress supply the low cost, low speed CY7C63000 Family controller, 
mainly intended for HID’s. The CY7C63001 is used in the Elektor-Elec- 
tronics Interface. One advantage for developers is the PDIP package out- 
line. Cypress provides documentation for different ‘reference designs’ 
which makes development easier. 


- Low speed USB 

- | Control endpoint, | Interrupt endpoint. (per 8 Bytes) 
- 8 Bit RISC-Processor 

- 6 MHz crystal, internal clock 12 MHz. 

- 128 bytes of RAM 

- 2K OTP (CY7C63000A) 

- 4K OTP (CY7C63001A) 

- Programmable current output port with a 4 Bit D/A 

- Package outline: PDIP 20, SOIC 20 


Motorola 

http://sps.motorola.com 

Friends of the HC05-Family are not left out. Motorola produce the 
68HC705]B3 low-speed USB Controller with 2 Interrupt endpoints. The 
68HC705]B4 also has an A/D converter. 


- Low speed USB 68HC705JB3 

- HCO05 core. 

- 2560 Bytes User ROM 

- 144 Bytes RAM 

- Low Speed |.5Mbps 

- | Control, 2 Interrupt endpoints 

- Package outline: PDIP-20/28 and SOIC 


- Low speed USB 68HC705JB4 

- HC05 core 

- 3584 Bytes ROM 

- 176 Bytes RAM 

- | Control, 2 Interrupt endpoints 

- 6 channel, 8 Bit A/D converter 

- Package outline: PDIP 28 and SOIC 28 


Microchip 

http://www.microchip.com 

If you prefer PIC controllers, Microchip produce these low-speed USB 
controllers. They include an A/D converter and a serial interface UART. 


PIC16C745 

- Low speed USB with 6 endpoints 
- 8 Bit A/D converter, 5 Inputs 

- 8k Program Memory 

- UART 

- Package outline: PDIP 20 


PICI6C765 

- Low speed USB with 6 endpoints 
- 8 Bit A/D converter, 8 inputs 

- 8k Program Memory 

- UART 

- Package outline: PDIP 40 
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unit USB1; 
interface 


uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, 
ExtCtris, StdCtris: 


type 
TForml = class(TForm) 
Timerl: TTimer; 
Edit1: TEdit; 
procedure FormCreate(Sender: TObject); 
procedure TimerlTimer(Sender: TObject); 
end; 


type _lin = record 
bFunction : Byte; 
bValuel : Byte; 
bValue2 : Byte; 
bValue3 : Byte; 
end; 


type  lOut = record 
bAck : Byte; 
bValuel : Byte; 
bValue2 : Byte; 
bValue3 : Byte; 
end; 


var 
Forml: TForml; 
Temp : Real; 


implementation 
{SR *.DFM} 


procedure Thermo; 

var lIn: lin; 
lout:  l0Out; 
DeviceHandle: THandle; 
TemplateHandle: THandle; 
nBytes: DWord; 
bresult: Boolean; 


begin 
DeviceHandle := CreateFile 

(‘\\.\Thermometer 0’,Generic write,File Share write,nil,open existing,0,TemplateHandle) ; 
lIn.bFunction := 11; {Read Thermometer} 
bResult := DeviceIoControl(DeviceHandle,$04,@lIn,sizeof(lIn),@1lOut,sizeof (lOut),nBytes,nil); 
Temp := l10ut.bValuel/2; 
lIn.bFunction := 23; {Write RAM} 
lin. bValuel := 47; {Adr. 47 = Port 1} 
if Temp > 37 then lIn.bValue2 := 0 else lIn.bValue2 := 15; 
bResult := DeviceIoControl(DeviceHandle,$04,@lIn,sizeof(lIn),@lOut,sizeof (lOut),nBytes,nil); 
CloseHandle (DeviceHandle); 

end; 


procedure TForml.FormCreate(Sender: TObject); 


begin 
Timerl.Interval := 100; 
Timerl.Enabled := true; 
end; 


procedure TForml.TimerlTimer(Sender: TObject); 
begin 

Thermo; 

Editl.Text := FloatToStrF(Temp,ffGeneral,3,2) + ‘°C’; 
end; 


end. 











Listing |. Control access in Delphi. 
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Table I. Format of the Device Descriptors 


Fieldname 
Blength 
BDescriptor Type 
BcdUSB 
BDeviceClass 
BDeviceSubClass 
BDeviceProtoco 
bMaxPacketSizeO 
IdVendor 
IdProduct 
BcdDevice 
IManufacturer 
Product 
[SerialNumber 


BNumConfigurations 


a printer, data will only be flowing in one 
direction so the USB bulk transfer method 
would be employed — control transfer would 
not be suitable here because it allocates time 
for data to flow in both directions. 

For control transfer methods the Windows 
function DeviceloControl is used. Listing 1 
shows the Delphi program that reads the 
temperature from the Elektor Electronics 
interface. The Windows Function CreateFile 
supplies a Handle to the device or rather its 
driver. The device name \\.\Thermometer_0 
is defined in the driver. With the valid handle, 
it will access the temperature reading. Lastly 
the device will be closed with CloseHandle. 
All these three Windows functions are 
declared in the Delphi 4 Windows unit. For 
more precise information, see Windows.pas 
and further information is in the help file 
WIN32.HLP 

Fach access with DeviceloControl requires 
a control code that is used to call one of the 
possible driver functions. Additionally two 
buffers need to be initialised, one input buffer 
and one output buffer. Both buffers require a 
maximum length of four bytes. In the listing, 
these buffers are defined as byte records. The 
flow direction of the data in the buffers is not 
defined, and a driver could use both buffers 
to send data in the same direction. In our 
example 1In sends data to the USB controller, 
while 1Out receives data from the device. 

To read the temperature, the value 11 (or 
OBhex) is sent as the first byte to the in 
buffer — this is done in the IIn.bFunction. 
The following positions bValue1 to bValue2 
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Length(in bytes), Description 

|, length of the Descriptor in Bytes 
|, Descriptor type (0|h=Device Descriptor) 
2, USB Version (V. 1.0) 

|, Class Code 

|, Subclass Code 

|, Protocol Code 

|, EPO-FIFO size 

2, Vendor ID (04B4h=Cypress) 

2, Product ID (02= Thermometer) 
2, Version number (V.09) 

|, String Index for “manufacturer” 
|, String Index for “Product” 

|, String Index for “Serial number” 


|, The number of possible configurations 


are used by the Read Thermometer 
function, not by the driver. If every- 
thing works correctly, the driver will 
return four bytes in lOut. The driver 
status indication is contained in 
bAck (1 indicates success). bValue1 
contains the temperature, bValue2 
the sign of the temperature value 
and bValue3 is the status of the 
pushbuttons. 

This example program imple- 
ments a thermostat to maintain a 
temperature of 37°C (ideal for incu- 
bating chicken eggs!). The output 
appears on the four output lines of 
Port 1 together with the green LED. 
While the Function 11 reads the 
temperature, Function 23 writes to a 
RAM address in the controller. Using 
Address 47, the Elektor Electronics 
firmware allows access to port 1. 
After each temperature measure- 
ment, a value of either 15 (all 1’s) or 
00 (all 0’s) will be sent out depend- 
ing on whether the temperature is 
too high or too low. To control the 
heater, a Power FET type BUZ10 can 
be used at the output to switch the 
current (Figure 2). For test purposes 
a 100-Q resistor (physically in con- 
tact with the temperature sensor) 
will serve as the heating element. 
Using a supply voltage of 5 V it will 
be possible for the resistor to reach 
the selected temperature. 

The complete Delphi Program can 


Example 
12h 
Olh 
00h, Olh 
00h 
00h 
00h 
08h 
B4h, 04h 
02h, OOh 
09h, 00h 
Olh 
02h 
00h 
Olh 


be downloaded from the author’s 

homepage: 
http://home.t-online.de/home/ 
B.Kainka 


The USB Driver 


Developers of USB devices can write 
the necessary device driver or they 
can build a device which already has 
an existing class driver. This option 
is however not available for applica- 
tions of control, measurement and 
regulation. The necessary prerequi- 
sites for developing a USB driver are 
C++ development environment and 
the Driver Development Kit (DDK) 
from Microsoft. This kit includes an 
example USB driver together with 
helpful additional information. Writ- 
ing your own driver is however not a 
trivial exercise, so the more exam- 
ples of driver code you can study, the 
better. Included along with the EZ- 
USB Starter kit from Anchor Chips is 
the complete source code for a ver- 
satile USB driver. Also worth a visit 
for a good introduction to USB is the 
website run by Craig Peacock 
(www.beyondlogic.org). He has also 
written a driver for the USB ther- 
mometer that can be used with the 
Elektor Electronics interface. 

(000094-2) 
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